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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3 GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 

"The User Data Convergence concept supports a layered architecture, separating the data from the application logic in 
the 3 GPP system, so that user data is stored in a logically unique repository allowing access from core and service layer 
entities, named application front-ends. Network elements and functionalities should be designed to access profile data 
remotely and without storing them permanently locally, i.e. the front-ends shall work in a user dataless configuration." 

TR 22.985 and TS 22.101 provide the requirements for User data convergence so that user data can be moved from 
where it originated, to a facility called User Data Repository (UDR) where it can be accessed, stored and managed in a 
common way. 

Convergence of user data unifies the user data access interface and its protocol. In addition, the logical centralization of 
user data implies the support of user data provisioning, that is, user data manipulation like creation, deletion, reading, 
modification and other operations. 

In order to accommodate multiple applications and services, existing and new ones, a framework for model handling 
and management of the UDC has been developed including: 

- UDC information model infrastructure 

- UDC information model handling 

- Application management 

- Consolidated data model management. 
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1 Scope 

The present document specifies the framework for overall management of the User Data Convergence. 

In order to accommodate multiple applications and services, existing and new ones, the framework for model handling 
and management of the UDC as identified by TS 22.101 includes the following items: 

- UDC information models: 

UDC information model infrastructure containing the common baseline information model (CBIM), 
application information models (AIM), and the specialised information model (SIM). The CBIM is 
standardised in TS 32.cde [4]. 

- UDC information model handling: 

provide a template and guidelines explaining the design of application information models to be used 
together with the common baseline information model to create the specialized information model 

describe the process to combine the common baseline information model with application information 
models in order to produce an operator- specific specialised information model 

- Application management data: 

- access control data for an application to UDC: identification and authentication 

- assignment to an application data model, including linkage to the consolidated data model 

- subscription rights for specific events on specific data of specific users 

- Consolidated data model management 

- lifecycle management of the consolidated data model in the UDR and in the provisioning entity. 

- activation/deactivation of application adaptation 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1]. 

Application Data Model : specific data model used by an application accessing the UDR. It is defined according to the 
UDC access protocol. Is related to an application information model. 

Application Data View: a function of the UDR that enables and limits applications access to data within the UDR. 

Application Information Model : specific information model used by an application accessing the UDR. It is defined 
with the same method as the common baseline information model. It is related to an application data model. 

Common Baseline Information Model: basic structure of UDC lOCs, see also definition in 3GPP TS 32.182 [4] 

Consolidated Data Model: Data model containing all data of the User Data Repository. It is the result of the 
implementation of the entire Specialized Information Model in the UDR for all applications. 

Information Model: Information Model denotes an abstract, formal representation of entity types, including their 
properties and relationships, the operations (e.g. read, write. . .) that can be performed on them, and related rules and 
constrains. In the information model, entities might have network topology relationship with each other. 

Specialized Information Model: Information model containing all information to be stored in the UDR. It is the result 
of operator specific specialisation of CBIM with addition of imported AIM. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [1]. 

ADM Application Data Model 

AIM Application Information Model 

AKA Authentication and Key Agreement 

AMF Authentication Management Field 

CBIM Common baseline Information Model 

CDM ConsoHdated Data Model 

ISIM IMS Subscriber Identity Module 

SpIM Specialised Information Model 

UDC User Data Convergence 

UDR User Data Repository 

UICC Universal Integrated Circuit Card 

USIM Universal Subscriber Identity Module 
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4 UDC Framework overview 

4.1 General overview 

TR 22.985 [2] and TS 22.101 [3] request the baseline information model to be future proof and extensible, i.e. new 
applications and/or new service profiles can be added by the operator, if necessary. The flexibility shall also permit new 
data for existing applications to be introduced, or modified. For the actual information model of an operator Specialized 
Information Model is described in TR 22.985 [2]. 

For the above purpose this specification defines and describes the infrastructure of UDC Information Models in Clause 

5. 

The correlation and handling of the UDC Information Models is described in Clause 6. 

4.2 Requirements coming from other Specifications 

TR 22.985 [2] and TS 22.101[3] provide requirements for CBIM and SpIM . These documents also mention the 
Application Data Models for the Access Interface to the UDC. 

Specification 23.335 [8] in Clause 5.2 defines the requirements for application access to the UDR including 
authentication and authorisation. 

Specification 29.335 [9]: defines as Access Protocol over the Ud interface LDAP (Clause 4) and as Data Model on the 
interface LDAP Directory Schema (Clause 7). 

4.3 Overview of UDC Data and Information Models 

Figures Fig.4.3-1 and Fig.4.3-2 below show the data and information models contained in the UDC framework 
including the UDR and the Application Front Ends. Boxes outlined in black, connecting Information and Data Models 
represent the process steps needed to produce the output model (pointed to by an outgoing arrow) from an input model 
(shown by the source of an incoming arrow). As shown in these figures, the Specialized Information Model can be both 
an input and output model, i.e. its current version is used as an input model to a process that generates an enhanced 
version when an Application Information Model new to the UDR is integrated and consolidated. 

Fig.4.3-1 below shows the case of internal integration model handling, where implementation of the Application is 
under responsibility of the operator . In this situation operator specification of the AIM leads to the Application Data 
Model (ADM), that gets implemented in the application FE and in the Application Data Model View in the UDR. 
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Figure 4.3-1 UDC Data and information iVIodels Overview with Operator integration model handling 

Figure 4.3-2 below shows the case of generation of the Application Data Model (ADM) for an Application/Front-End 
when the development of the application is not the responsibility of the operator. In this situation, both the CBIM and 
the AIM of the application are used to generate the ADM being implemented in the Application/Front-End. 
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Figure 4.3-2 UDC Data and Information Models Overview with separate ADM generation for the 

Application/Front-End 



5 UDC information model infrastructure 

5.1 Common Baseline Information Model (CBIM) 

CBIM provides the basic structure of UDC lOCs. It shall enable an operator to integrate the user data to be stored in the 
UDR. 

5.2 Application Information Models (AIM) 

NOTE: The present clause introduces AIM. AIM may be imported from existing applications or may be generated 
from information elements already existing in the UDR. 

An AIM should contain lOCs for 

- the Service Profile(s) of the particular application, 

- Identifier(s) used by the application 

and additionally, if needed, any other IOC defined in CBIM. E.g. related End Device, if such is to be connected to one 
or more identifiers within the application. 
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5.3 Specialised Information Model (SplM) 

NOTE: The present clause describes building the SpIM from CBIM and AIMs with consolidation of semantically 
identical data. 

SpIM is the Information model containing all information to be stored in the UDR. A Specialized Information Model is 
operator specific. An implementation of the entire Specialized Information Model in the User Data Repository for all 
the applications leads to the Consolidated Data Model. 



UDC information model handling 



6.1 



General 



The relations of the UDC information models are depicted in Figure 6.1-1 below. 
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Fig. 6.1-1 UDC Information Models 

Figure 6.1-2 below shows the process that leads to integrating and consolidating data for a given operator from the 
UDR perspective. 

Initially the Common Baseline Information Model (CBIM) is specialised according to the service and user structure of 
the given operator resulting in the initial version of the operator" s the Specialized Information Model (SpIM). 

The actual version of the operator" s Specialized Information Model (SpIM)) is combined together with one or more 
Application Information Models (AIMs) to form a new version of the Specialized Information Model (SpIM) of the 
operator. The SpIM represents and considers all the data of all converged services offered by the operator. 

It is the decision of the operator, when a new actual version of the SpIM is implemented into the UDR. An 
implementation of the actual version of the SpIM into the UDR leads to the Consolidated Data Model (CDM), which is 
representing the actual implementation of the UDR. 
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Figure 6.1-2: UDC Information and Data Models in the UDR 



Consider now integration for a given application. An Application Data Model (ADM) has to be developed both for the 
UDR and for the Application/Front-End to be used on the Ud interface. 

In the integrated model handling environment under responsibility of the operator implementation of the SpIM and the 
AIM of the application leads to the Application Data Model (ADM), this is depicted in Figure 6.1-3. The ADM gets 
implemented in the application FE and in the Application Data Model View in the UDR. 
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Figure 6.1-3: UDC Information and Data Model handling for an Application Type in an integrated 

Operator environment 
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In the case of separate development of the AppHcation Data Model (ADM) for an application on the Application/Front- 
End side, implementation of the CBIM and the AIM of the application leads to the ADM being implemented there. This 
is depicted in Figure 6.1-4. 



Common Baseline IM 
(CBIM) 



AppI IM (AIM) 



Application Data Model 
(ADM) 



Figure 6.1-4: Separate Information and Data Model handling for an Application Type for Application 

Front-End 



6.2 Initial SplM Creation from CBIM 



The Specialized Information Model is initially generated through operator specific specialisation of CBIM e.g. through 
definition of the operator- specific End-User groupings. 

6.3 AIM Integration into SplM 

After the initial SplM has been created, AIMs are imported and consolidated into it. The SplM takes into account the 
specific applications, the functionality included and the relevant business information. 

6.4 Consolidation of User Data in the SplM 

6.5.1 Example of consolidation of data in the SplM using aggregation 

The Figure 6.5.1-1 below provides an example of building the SplM by aggregating semantically identical data. 
Attributes that are common to at least two different service profiles are defined in lOCs than are then aggregated to 
these service profiles. For example, the Roaming 1 IOC contains roaming data that is common to both PS and CS 
service profiles, 0DB3 contains operator determined barring data that is common to both PS and EPS service profiles 
and Trace contains data that is about subscriber and equipment trace common to all PS, CS, EPS and IMS profiles. 
Using aggregation means that the attribute value will be always same in each of the service profile that has aggregated 
the IOC where the attribute is defined. Note also that this example only shows how a portion of the data can be 
consolidated using aggregation. 
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Figure 6.5.1-1 : Consolidation of data in the SplM using aggregation. 

6.5.2 Example of specialization for authentication methods 

Figure 6.5.2-1 shows an example of how the CBIM can be further speciaHzed for the purpose of considering different 
authenticatio-n methods. 
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Figure 6.5.2-1 : Authentication methods 



6.5.3.1 



AkaUsim 



6.5.3.1.1 



Definition 



This object class represents data that is required to perform Authentication and Key Agreement (AKA) when the UE is 
equipped with a USIM. For details of AKA see subclause 6.3 in 3GPP TS 33.102 [6]. For example, an encrypted 
subscriber key and the AMF can be attributes of this object class. 



6.5.3.2 



CsAka 



6.5.3.2.1 



Definition 



This object class represents data that is required to perform AKA when accessing Circuit- Switched services, such as the 
sequence number used for AKA authentication to access CS services. For details of AKA see subclause 6.3 in 
3GPPTS 33.102 [6]. 



6.5.3.3 



PsAka 



6.5.3 3.1 



Definition 



This object class represents data that is required to perform AKA when accessing Packet- Switched services such as the 
sequence number used for AKA authentication to access PS services. For details of AKA see subclause 6.3 in 
3GPPTS 33.102 [6]. 
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6.5.3.4 EpsAka 
6.5.3.4.1 Definition 

This object class represents data that is required to perform AKA when accessing Evolved Packet- Switched services, 
such as the sequence number used for AKA authentication to access EPS services. For details of AKA see subclause 6.3 
in3GPPTS33.102[6]. 

6.5.3.5 ImsAkalsinn 
6.5.3.5.1 Definition 

This object class represents data that is required to perform IMS AKA for accessing IMS services when the UE is 
equipped with a UICC that contains an ISIM, for example, the encrypted subscriber key and AMF that is used for 
accessing IMS services. For details of IMS AKA see subclause 6.1 in 3GPP TS 33.203 [7]. 

6.5.3.6 InnsAka 
6.5.3.6.1 Definition 

This object class represents data that is required to perform IMS AKA when accessing IMS services, such as the 
sequence number used for AKA authentication to access IMS services. For details of IMS AKA see subclause 6.1 in 
3GPPTS 33.203 [7]. 

6.5.3.7 InnsAkaUsinnlsinn 
6.5.3.7.1 Definition 

This object class represents the data that is required to perform IMS AKA for accessing IMS services when the UE is 
equipped with either a USIM or an ISIM, for example, the realm. It aggregates the ImsAka object class and one of the 
AkaUsim or ImsAkalsim object classes, depending on whether the UE is equipped with a USIM or an ISIM, 
respectively. For details of IMS AKA see subclause 6.1 in 3GPP TS 33.203 [7]. 

6.5.3.8 GprslnnsBundled 
6.5.3.8.1 Definition 

This abstract object class represents the data that is required to perform GPRS -IMS bundled authentication. For details 
of the NASS-IMS bundled authentication see 3GPP TS 33.203 [6] Annex T. 

NOTE: This object class is set to be abstract because it does not need any new particular data. The GPRS-IMS 
bundled authentication requires the IPv4 address or Ipv6 prefix allocated by GPRS to the UE, therefore, 
data that is stored elsewhere. This object class is merely here for completeness, but need not be 
implemented. 

6.5.3.9 NasslnnsBundled 
6.5.3.9.1 Definition 

This object class represents the data that is required to perform NASS-IMS bundled authentication, such as the line 
identifier. For details of the NASS-IMS bundled authentication see 3GPP TS 33.203 [6] Annex R. 
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6.5.3.10 SipDigest 
6.5.3.10.1 Definition 

This object class represents the data that is required to perform SIP Digest authentication for accessing IMS services. 
For example, it includes the H(A1) parameter of HTTP Digest, the realm, QoP, and Algorithm directives in HTTP 
Digest authentication. For details of the SIP Digest authentication see 3GPP TS 33.203 [6] Annex N. 

6.5 Construction of AIM 

An AIM comprises all the information required by an application. In the construction of an AIM, the following 
possibilities exist with respect to the current version of the SpIM: 

- AIMs may be constructed from new information not yet present in the current version of the SpIM. 

- AIMs may be constructed by using information that already exists in the current version of the SpIM. 

- AIMs may be constructed requiring both new information and information that already exists in the current version 
of the SpIM. 



7 Application management 

7.1 Application Access Control Data 

Specification 23.335 [8] in Chapter 5.2 defines the requirements for application access to the UDR including 
authentication and authorisation. 

To be able to authenticate an application and to provide it access data in the UDR the following have to be stored: 

- identity of the application including additional access protocol dependent authentication information (e.g. 

password) 

- type of the application with associated Data Model 

To be able to authorise an application for access to data in the UDR the following have to be stored: 

- allowed PLMN-Id(s) 

- allowed operations with the associated Data Model 

- restrictions on operations possibly at information element level. 

7.2 Application Data Model and Mapping to Consolidated Data 
Model 

7.2.1 Application Data Views 

Different applications have different needs when accessing the data. Consider a piece of data: some applications may 
need to read and write that data; other applications will only need to read the same data; and a third group of 
applications should not be able to access that data at all. Since the UDR implements the CDM, there must exist a 
mechanism to control the access of data per application, so that only the authorised subset of the CDM is exposed to 
that application with the correct access permissions, details on primary access control are to be found in Chapter 7.1 of 
this specification. 

Access only to the authorised subset of the CDM is achieved by implementing Application Data Views in the UDR 
connected to the different application types. The concept is illustrated in Figure 7.2.1-1 in a simplified way. A detailed 
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figure is given in Figure 7.2.1-2, and a more developed concept (considering different vendors) is provided in Figure 

7.2.1-3. 

According to Figure 7.2.1-1 , the UDR implements the CDM. AppHcation Data Views are implemented for each 
application type accessing its specific user data within CDM in the UDR. The Application Data View is responsible for 
enabling and limiting applications access to data within the UDR. 




FE2 



Figure 7.2.1-1 : Application Data Views in the UDR (simplified) 



App 
Data 
View 


App Data 
Model 


App Data 

Model 
Mapping 


Capabilities 
for Apps 



AppI IM (AIM) 




Specialized 
IM (SplM) 



Figure 7.2.1-2: Correlation of IM and Application Data View for a single Application type in the UDR 

In a multi-vendor scenario, for a given application type, each Front End vendor and application version may implement 
their own data model. Therefore, data models for the same application need not be equal across different vendors or 
release of the software. This scenario conceptually requires a different application data model mapping for each 
application and vendor. The concept is illustrated in Figure 7.2.1-3. For each application type, there can be a number of 
Application Data Views, each one handling the mapping to the particular data model of the vendor of the Front End. 
For example, for Application type #1, there can be three Front End vendors, named FEli, FEI2, FEI3, respectively. 
Each of these front ends implements its own data model. A different Application Data View handles the correct 
mapping to each data model. In Figure 7.2.1-3, Application Data View li manages FEli, Application Data View I2 
manages FEI2, Application Data View I3 manages FEls^ and so on 
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; 


^ FE32 




Figure 7.2.1-3: Application Data Views in tlie UDR 



7.3 Subscription and Notification Related Data 

Specification 23.335 [8] in Chapter 5.7 and 5.8 defines the procedure of subscription and notification. Specification 
29.335 [9] in Chapter 6.6, 6.7 and Annex A defines the content and format of the subscription and notification messages. 

Subscription can be done by subscription message (dynamic) or configuration of the UDR (permanent). To support both 
kinds of subscription and to allow authorised unsubscribe operations, the following information should be stored in the 
UDR: 

type of subscription, dynamic or permanent 

user identifier, e.g. IMSI, MSISDN, IMS public user identity or IMS private user identity, if not specified the 
subscription is applicable to all users" data of the application in the UDR. 

information on the data requested to be observed 

identity of the original (originating) subscribing entity identity, this item indicates the original entity which sent 
the subscription request message to the FE in order to subscribe to the notification of the specific events of the 
data requested to be observed 

notification condition(s), this item indicates the specific events on which the notification shall be triggered. The 
triggering events shall consist of one or more of the following: the addition of the observed data, the deletion of 
the observed data or the changes of the observed data. 

type of notification, this item indicates whether this subscription request should lead to a notification to any FE 
of the application type or cluster identifier, or to a notification to the FE requesting the notification.to 
originating entity or to an FE/application based on actual selection 

To support dynamic subscriptions the following information has to be stored in the UDR: 

the subscription expiry time 

the identifier of the FE or the FE Cluster which sent the subscription message (conditional, if the notification 
type indicates that the notification is to be sent to the FE requesting the subscription, this item is needed.) 

To support the notification of data modification, the following information should be stored in the UDR: 
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additional data to be sent to the application in the notification when the notification condition is met 

the FE selection algorithm (conditional, if the notification type indicates that the notification is to be sent to any 
FE of the application type or cluster identifier, this item is needed. This is only the identifier of the selection 
algorithm, not the algorithm itself.) 

If the Notification Type indicates that the notification is to be sent to any FE, when the notification condition is met, the 
UDR should use the FE select algorithm to select a proper FE to notify. For example, the UDR may select to notify the 
application actually serving the user. 



8 Consolidated data model management 

8.1 Lifecycle Management of the Consolidated Data Model in 
the UDR 

Figure 8.1-1 below shows the operational environment of UDC according to Figure 4.3-1. The Provisioning Gateway is 
an additional aspect which is essential for the operation of the UDR. The Provisioning Gateway provides a single 
logical point for consistent provisioning of user data for all services in the UDR. The mechanism used by the 
Provisioning Gateway to access UDR data using the CDM is outside the scope of the present document. The 
Application boxes denote Application Front Ends including Provisioning Front Ends according to 23.335 [8]. The 
Provisioning Front Ends access UDR data via the Ud reference point and are restricted by their Application Data 
Model. 

Chapter 4.3 describes how AIM(s) may be added and consolidated into the SpIM and the generation of the Application 
Data Model and its mapping to the CDM. It is the decision of the operator when the newly added AIM(s) may become 
operational. 

It is the decision of the operator, when a new actual version of the SpIM with the newly added AIM(s) is implemented 
into the UDR as actual version of the CDM. 

The Provisioning Gateway provides a view of the actual version of the CDM to enable provisioning of all data stored by 
different applications in the UDR. 

The CDM implementation into the UDR is an atomic operation. 
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Figure 8.1-1 : Evolution of the CDM in a UDR 

8.2 Activation and Deactivation of Application Adaptation 

As described above the operator shall be capable of 

- adding new AIM to SpIM, described in Chapter 4.3 

- adding ADM to UDR together with adaptation to CDM as described in Chapter 4.3 and 8.1. 

- generate and activate new actual CDM based on the current SpIM as described in Chapter 8.1 above 

- activate the access of the application to its data in the UDR which can only be done after the implementation of the 
CDM containing that data and is done by associating the proper Application Data View to the application. 

- deactivate the access of the application to its data in the UDR which is needed when, for example, the data of the 
application have changed Deactivation is done by deleting the current association of Application Data View to the 
application. 



ETSI 



3GPP TS 32.181 version 9.0.0 Release 9 22 ETSI TS 132 181 V9.0.0 (2010-07) 

9 Relation to other Information Models 

9.1 Relation to SuM Network Resource Model 

The 3GPP SuM NRM as defined in the TS 32.172 [10] contains the information model related to the provisioning of 
the data of 3 GPP services stored in the UDR. 
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